\section{Local Application Support / OCS Support}
\label{sec:Local_Application_Support__OCS_Support}

This section dedicated to Local Application Support and OCS Support,
presents Jean-Christophe \textsc{Pierson} additionnal part of the job.

\subsection{Local Application Support}
\label{sec:LAS}
Local Application Support is a very intersting part of my job in
\MARS{}. I learned a lot by going through different business areas and
discuss with people on how they use computers and sofwares to increase
their efficiency at work.

We can split Local Application Support in two parts:
\begin{itemize}
\item day to day support
\item leading projects
\end{itemize}

\subsubsection{Day to day support}
To do their job, most of \MARS{} office associates use a
computer. They use some applications which are suppoted centrally by
global teams, but some are local and supported locally, by Local
Application Support team which is called
\tsf{FAST}\,\footnote{\tbf{F}rench \tbf{A}pplication \tbf{S}upport
\tbf{T}eam} in France.

Support requests arrive from different way:
\begin{itemize}
\item directly from the user, by email to the team mailbox, by phone,
by Instant Message or face to face when the user is on site;
\item from GTS\,\footnote{\tbf{G}lobal \tbf{T}echnology \tbf{S}upport}
which is \MARS{} SPOC\,\footnote{\tbf{S}ingle \tbf{P}oint \tbf{O}f
\tbf{C}ontact} for support request. In this case request usually
arrive through our incident and change management tool: \tsf{MAGIC};
\item from other teams. Here, request could arrive through email or
through \tsf{MAGIC}.
\end{itemize}

Support requests from the user could be for exemple:
\begin{itemize}
\item give access to an application to a user;
\item reinstall an application because the user move from one computer
to another one;
\item re run processes because something wrong happens in the
automatic process;
\item correct data manually because user click the wrong button and
the application has no rollback support;
\item etc.
\end{itemize}


\subsubsection{Leading projects}
Leading projects is more about long term evolution. It could be for
example:
\begin{itemize}
\item feasability study for an application replacement
\item answer the business needs and provide them a complete solution
\item retire old application but find a solution to keep data like
invoices in a safe place because of laws
\item etc.
\end{itemize}

\subsection{OCS support}
\label{sec:OCS_support}

OCS is a VMI\,\footnote{\textbf{V}endor \textbf{M}anaged
\textbf{I}nventory} tool. This is a business model where customer
provides inventory information to \MARS{} and \MARS{} take the
responsability for maintaining stock cover in the customer warehouses.

\subsubsection{Classical business model}
Classical business model is when the customer send an order to
\MARS{}, and we execute it, send a truck to the customer warehouse
with the required items. Then \MARS{} send an invoice to his customer.
You can see that classical process on
figure~\ref{fig:classical_business_model}.

\begin{figure}[!htbp]
	\centering
	\includegraphics[width=\lfig]{graph/classical_business_model}
	\caption{Classical business model}
	\label{fig:classical_business_model}
\end{figure}


\subsubsection{VMI business model}
In VMI business model, customer and \MARS{} agree on stock cover in
days for each item. The customer send each night his warehouse
despatches and stocks levels. Then \MARS{} runs \OCS{} and build 
order proposal. If the sales weren't high enougth to build a full
truck, OCS complete it with some other items based on the despatch
history. \MARS{} decided to send always full trucks in order to
optimise costs. Then order proposal is sent both to the customer and
to the \MARS{} financial system, and the truck goes to the customer
warehouse. Figure~\ref{fig:vmi_business_model} show the MVI process
with numering steps.

\begin{figure}[!htbp]
	\centering
	\includegraphics[width=\lfig]{graph/vmi_business_model}
	\caption{VMI business model}
	\label{fig:vmi_business_model}
\end{figure}

Advantages are clear:
\begin{itemize}
\item increase confidence between \MARS{} and our customers;
\item share information, share risk;
\item reduce stock level in the customer wharehouses;
\item assure product disponibility in the supermarket;
\item \MARS{} can calculate prevision and adapt his production
regarding the information from customer;
\end{itemize}


\subsection{OCS migration project}
\label{sec:OCS_migration_project}
The main objective is to provide a new version of the application to
the users and put this application on a new server in
MTO\,\footnote{Mont Olive} data center. Then we remove local solution
and the user can access OCS application through Citrix.

Impacted countries are in order:
\begin{itemize}
\item Portugal
\item Spain
\item Switzerland
\item Italy and Germany are planned for september/october
\item Belgium, Holand, Poland are still in discussion today.
\end{itemize}

Steps for this migration project are:
\begin{itemize}
\item Confirm project plan and timetable
\item enable version 9 at Citrix server
\item provide access to the central MTO server
\item setup a testing environment
\item trainning
\item migrate local data do central server
\item testing
\item load data into production system
\item branch EDI messages to production environment
\item go live / parallel run
\item decide / remove old OCS from local server
\item input to template development
\end{itemize}

Figure~\ref{fig:local_ocs_architecture} present the local
situation.
\begin{figure}[!htbp]
	\centering
	\includegraphics[width=\lfig]{graph/local_ocs_architecture}
	\caption{Local OCS architecture}
	\label{fig:local_ocs_architecture}
\end{figure}

Figure~\ref{fig:global_ocs_architecture} present the new global
solution in MTO.
\begin{figure}[!htbp]
	\centering
	\includegraphics[width=\lfig]{graph/global_ocs_architecture}
	\caption{Global OCS architecture}
	\label{fig:global_ocs_architecture}
\end{figure}


